Embodiments of the present invention relate to software applications, and more particularly relate to techniques for managing aspects of application upgrades.
Upgrades (i.e., patches) for data-driven software applications typically include a number of data upgrade files. These data upgrade files are run against a back-end database of the application, and are generally used to migrate existing application data, seed new application data, and/or modify the application data model to support new and/or enhanced features. In many cases, the execution of one data upgrade file in a patch run will depend on prior executions of one or more other data upgrade files in the patch run. Thus, it is important to track these dependencies and sequence the execution of the data upgrade files accordingly.
In practice, most software developers and development teams do not follow an organized methodology for tracking and managing upgrade dependencies. Rather, they typically determine how to order the execution of data upgrade files within a particular patch run on ad-hoc, file-by-file basis. For example, assume development team A creates an upgrade script “A.sql” and places A.sql in execution phase “X” of an upgrade. Further, assume development team B subsequently creates an upgrade script “B.sql,” which depends on A.sql. Observing that A.sql is set to run in phase X, development team B may decide to place B.sql in a random downstream phase “X+Y” to ensure that B.sql executes after A.sql.
Typically, team B will not be aware of other data upgrade files created by other teams that are also dependent on A.sql. Similarly, team A may not be aware of downstream dependencies on A.sql. (e.g., B.sql). This creates several problems. First, different developers/development teams cannot effectively consolidate the execution of data upgrade files across functional/team boundaries, often resulting in unnecessary execution phases within an upgrade. For example, assume development team C creates an upgrade script “C.sql,” which is dependent on A.sql (but independent of B.sql). Like team B, team C may decide to place C.sql in an execution phase that is downstream from phase X to ensure that C.sql executes after A.sql. However, since team C is unaware of B.sql, team C may decide to place C.sql in a random downstream phase “X+Z” that is different from phase X+Y. As a result, B.sql and C.sql are forced to execute serially, even though they are independent and can be executed simultaneously (i.e., in the same phase). This type of situation undesirably increases the total running time of the upgrade and the downtime of the system to be patched.
Second, development teams cannot easily modify the execution order of data upgrade files within an upgrade without breaking downstream dependencies. For example, if team A moves A.sql to a later execution phase “X+A” (perhaps because of an upstream dependency change) the dependency between A.sql and B.sql and/or the dependency between A.sql and C.sql may be broken. Even if B.sql and C.sql are moved in response to A.sql, those changes might break additional downstream dependencies. The key problem is that no one has a holistic view of all of the inter-file dependencies that may be included in an upgrade. As a result, it is extremely difficult, particularly for large and complex upgrades, to anticipate all of the downstream effects of modifying the sequencing of data upgrade files.
Accordingly, it is desirable to have improved techniques for managing the dependencies of an application upgrade.